home *** CD-ROM | disk | FTP | other *** search
/ Power Tools 1993 November - Disc 2 / Power Tools Plus (Disc 2 of 2)(November 1993)(HP).iso / hotlines / gsyhl / hawhite / append.txt < prev    next >
Text File  |  1993-05-12  |  7KB  |  139 lines
  1.  
  2.      APPENDIX A -- SwitchOver/UX Product Operation
  3.  
  4.      SwitchOver/UX consists of a set of programs running on the primary and
  5.      the standby hosts.  (A host is the collection of programs and data used
  6.      by a processor.) There are two "daemon" programs which are used to
  7.      monitor the state of the primary hosts.  (A daemon program is one which
  8.      runs automatically in the background to provide certain system
  9.      services.) A primary host in a highly available group runs a daemon
  10.      called heartbeat.  This program periodiclly transmits a message to the
  11.      standby host over the local area network.  The standby host runs a
  12.      daemon called readpulse, which "listens" for the heartbeat messages.
  13.  
  14.      There are five phases to SwitchOver/UX's operation:
  15.  
  16.          1)  Normal health checking
  17.          2)  Fault detection and recovery
  18.          3)  Application recovery
  19.          4)  Resume processing
  20.          5)  Processor repair
  21.  
  22.      Normal Health Checking During normal operation, each primary in a
  23.      loosely-coupled processor group sends out a "heartbeat" across the LAN
  24.      to the standby system informing it that everything is functioning
  25.      properly (Figure 1).  The standby system "listens" for these heartbeats
  26.      and as long as it receives these heartbeats, it will continue to run
  27.      its own applications.
  28.  
  29.  
  30.      Fault Detection and Recovery
  31.  
  32.      When the standby misses a "heartbeat" from a primary processor, it
  33.      assumes the primary has failed and begins the recovery process (Figure
  34.      2).  First, the standby processor locks the root disk of the primary
  35.      processor.  This prevents the primary processor from inadvertently
  36.      accessing the disks and possibly corrupting data once the standby has
  37.      assumed the responsibilities of the failed primary.  Next, the standby
  38.      reboots itself using the root of the failed system.  When the standby
  39.      finishes rebooting, it will also have the network address of the failed
  40.      system.
  41.  
  42.      NOTE: Once the standby initiates the recovery process, it can not be
  43.      reversed until the processor recovery is completed.  Also, any disks
  44.      the standby was accessing prior to recovery will not be accessible
  45.      until the failed primary is repaired.
  46.  
  47.  
  48.      Application Recovery
  49.  
  50.      After the standby system has finished assuming the identity of the
  51.      failed system, the application needs to go through their own recovery
  52.      routines.  Most databases support recovery from a reboot and can
  53.      automatically bring themselves to a consistent state.
  54.  
  55.      Custom applications need to be structured to recover from a reboot.
  56.      Applications can be automatically restarted through the use of HP-UX's
  57.      standard initialization and start-up files.
  58.  
  59.  
  60.      Resume Processing
  61.  
  62.      Users log back into the system using their normal procedure, and
  63.      re-start their individual applications.  Users do not need to know that
  64.      they are running on a different processor (Figure 3).  For most
  65.      database applications, users may need to check on their last
  66.      transaction before processing was interrupted.  Typically, the current
  67.      transaction will be lost when processing is interrupted.  The amount of
  68.      data loss will depend upon the individual application and database.
  69.  
  70.      Batch applications which are interrupted will also need to be
  71.      re-started.  Depending upon the recovery capabilities of the
  72.      application, either it will need to be re-started from the beginning or
  73.      from a point where the state of the program and data are consistent.
  74.  
  75.  
  76.  
  77.  
  78.      After the standby has assumed the responsibilities of the failed
  79.      primary, it becomes the primary and the failed primary is treated as a
  80.      standby system.  The failed system is then repaired using HP's normal
  81.      repair processes with the assistance of a system administrator or
  82.      repair technician.  Once the system is repaired, it can be brought up
  83.      as a standby for the other primaries or it can resume being a primary
  84.      (Figure 4).  In order to return the failed primary to being a primary
  85.      again, the standby which took over for the primary will need to be
  86.      shutdown so the primary can regain its disks and network address.  This
  87.      switchover should be scheduled when the system is lightly loaded and
  88.      users can afford the brief downtime.
  89.  
  90.      Recovery Time
  91.  
  92.      The recovery time for a system is very application dependent.  Figure 5
  93.      diagrams the recovery process and shows which stages are time dependent
  94.      upon customer applications. There are three key components to recovery
  95.      time:
  96.  
  97.          1) Fault detection
  98.          2) System recovery
  99.          3) Application recovery
  100.  
  101.  
  102.      Fault Detection
  103.  
  104.      Fault detection is determined by the frequency of the heartbeats and
  105.      how many heartbeats the standby will allow to go by before it initiates
  106.      recovery procedures.  These two parameters are definable by the system
  107.      administrator.  Typically this stage of the recovery process will take
  108.      less than one minute.
  109.  
  110.  
  111.      System Recovery
  112.  
  113.      During system recovery the standby processor reboots and checks all
  114.      disk file systems to correct any problems that may have been created
  115.      when the primary processor failed.  The reboot time is dependent upon
  116.      the class of machine (i.e.  827, 832, etc.) and the amount of RAM
  117.      memory.  The disk checking time depends on how much disk space is used
  118.      for the file system and the state these files were in at the time of
  119.      the failure.  This component may be the largest part of the recovery
  120.      time.  It may be significantly reduced by using databases and
  121.      applications which access the disks directly and bypass the HP-UX file
  122.      system.  The most recent versions of industry leading database products
  123.      typically bypass the file system (using raw disk) which helps to
  124.      minimize recovery times.
  125.  
  126.  
  127.      Application Recovery
  128.  
  129.      Once the processor has recovered and the file system is intact, the
  130.      application needs to perform its own recovery.  For databases this
  131.      would mean rolling transactions back to a known state and then rolling
  132.      them forward, completing all committed transactions and discarding all
  133.      incomplete transactions.  The time it takes for this stage is entirely
  134.      dependent upon the application and the transaction rate prior to the
  135.      failure.  This portion of the recovery time can be minimized by
  136.      choosing databases and structuring applications to recover quickly from
  137.      system reboots.
  138.  
  139.